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REMARKS 

Claims 40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 are pending and stand rejected. 
Claims 71-75 are rejected under 35 U.S.C. § 1 12, ^ 2 as being indefinite for failing to particularly 
point out and distinctly claim the subject matter which the Applicants regard as the invention. 
Claims 40-42 and 55-56 are rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 5,243,331 to McCausland et al. ("McCausland") in view of U.S. Patent No. 5,915,209 
to Lawrence ("Lawrence"), U.S. Patent No. 5,809,483 to Broka et al. ("Broka"), U.S. Patent No. 
5,101,353 to Lupien et al. ("Lupien"), Admitted Prior Art ("APA"), and U.S. Patent No. 
7,231,363 to Hughes et al. ("Hughes"). Claims 61-65, 67-69, 71-72 and 74-75 are rejected under 
35 U.S.C. § 103(a) as being unpatentable over McCausland in view of Lawrence, Lupien, and 
Hughes. Claims 58-59 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
McCausland in view of U.S. Patent No. 6,343,278 to Jain et al. ("Jain"), Lupien, APA and 
Hughes. 

Upon entry of this paper, claims 40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 will be 
pending in the application and are presented for consideration. Applicants hereby amend claims 
40, 58, 61 and 71. These claim amendments do not introduce new matter to the application. 
Support for the claim amendments can be found throughout the specification, including, e.g., at ^ 
[0090] of U.S. Published Patent Application No. 2002/0156719 ("Applicants' Specification"). 

I. Rejection of Claims under 35 U.S.C. § 112, f 2 

The Office Action rejected claims under 35 U.S.C. § 112, f 2 as allegedly being vague. 
(Office Action at 3.) Specifically, the Office Action states that the limitation "the predetermined 
order conditions associated with the match are invalid and result in a locked or crossed market" 
is vague. Id. Although the Office Action refers to claims 71-75, Applicants respectfully submit 
that independent claims 40, 58 and 61 (and the associated dependent claims) also contain this 
limitation, so Applicants respectfully traverse with respect to all claims. 

Claims 40, 58, 61 and 71 recite: 

preventing, by the computer trading system, a match of the 
received trading orders when the predetermined order conditions 
associated with the match result in a locked or crossed market. 
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In Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result. Users may unlock or 
uncross a market by, e.g., entering an order with a better price 
than the displayed order locking: or crossing the market , even if the 
order has a minimum price difference between the displayed order 
locking or crossing the market. Moreover, under certain conditions 
trading may then occur at a price less than the newly entered better 
price. In sum, a locked market can be effectively unlocked without 
necessarily causing a trade to occur at a better price than the 
order locking the market . 

(Applicants' Specification at [0090] (emphasis added).) 

The Office Action asks the question, "[w]hat is locked/cross marked (order or matching 
engine) and 'locked or cross marked' for what?" (Office Action at 3.) Applicants respectfully 
submit that the claim recites "the predetermined order conditions associated with the match result 
in a locked or crossed market ," not "marked." Applicants submit that it is well-known that a 
locked market occurs when both the bid price and the ask price of a security are equal, resulting 
in no bid-ask spread. Applicants further submit that that it is well-known that a crossed market 
occurs when the bid price of a security exceeds the ask price, resulting in a negative bid-ask 
spread. 

The Office Action argues that "[w]hen both orders are locked or crossed marked, mean 
they are invalid/blocked/locked orders and could not be matched with the remaining of the order 
list (plurality of orders), since they are locked." (Office Action at 3.) The Office Action also 
states that "if the orders match (B pit i matched O pjt j), they (orders B piti & O pitj ) should be blocked 
form [sic] further matching and taken out (moved/removed) of the order list." Id. at 3. However, 
Applicants submit that claims 40, 58, 61 and 71 recite "preventing, by the computer trading 
system, a match of the received trading orders when the predetermined order conditions 
associated with the match result in a locked or crossed market." As set forth above, the locked or 
crossed market can be unlocked or uncrossed, e.g., via entry of another order with a better price 
(Applicants' Specification at [0090]), which does not render the order that locked or crossed the 
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market "blocked form [sic] further matching," as the Office Action suggests. (Office Action at 
3.) 

In light of the above remarks, Applicants respectfully request that the rejection of claims 
40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 under 35 U.S.C. § 112, second paragraph, be 
reconsidered and withdrawn. 

II. Rejection of Claims 40-42 and 55-56 under 35 U.S.C. § 103(a) 

The Office Action rejected claims 40-42 and 55-56 under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of Lawrence, Broka, Lupien, APA, and Hughes. (Office 
Action, pp. 4-11.) For a rejection under § 103 to be proper, the references must expressly or 
impliedly suggest the claimed invention taken as a whole. Additionally, the combination must 
not render either reference inoperable. As set forth below, McCausland fails to teach or suggest 
each and every element of claim 40, from which claims 41, 42, 55 and 56 depend. Lawrence, 
Broka, Lupien and Hughes fail to cure the defects of McCausland. 

a. McCausland Fails to Teach Each and Every Element of Amended Claim 40 

The Office Action states that McCausland does not explicitly disclose the order types 
"Fill or Kill", "Minimum Fill", "Lots Of, "Show Only", "Good Until a time of day", or "Good 
For a period of time" recited in claim 40. (Office Action at 6.) The Office Action also states that 
McCausland does not explicitly disclose the "receiving... authorization" step, the "transmitting" 
step, the "enabling... at least one of the first and second traders to complete..." step, the 
"matching" step, and the "preventing" step. Id. at 6-7. The Office Action states that McCausland 
does not explicitly disclose "presenting [sic] a match responsive to said predetermined order 
conditions." Id. at 7 (emphasis added). Applicants respectfully interpret this statement to apply 
to the "preventing" step of claim 40. 

McCausland describes a "computer system and program for trading securities comprising 
a central host computer system, plural personal computer-based trading stations geographically 
remote from the host system, a communications network connecting the trader stations to the 
host system, and a special-function keypad attached to the trading station for interacting with the 
system." (McCausland at 2:40-47.) McCausland describes order entry and execution as follows: 
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All orders in the trading system 10 are limit orders as that term is 
understood in the art and are "live" until canceled. The system 
accepts one bid and one offer per issue for that trader, and any 
change in market price or size cancels the previous order. 



To enter an order (Bid or Offer) or execute an order (Hit or Take), 
a trader follows the following steps. First, the trader highlights the 
desired issue. Second, the trader presses one of the action keys 226, 
228, 230 or 232: BID, OFFER, HIT or TAKE. The selected action 
is displayed on the Action Line. To change the size or value of the 
requested transaction, the trader can type a size next to the action if 
desired, or keep the default. The [Enter] key is then pressed. The 
order for the issue selected is displayed in a small window on the 
trader's page. To change a price, the trader can tick the price up and 
down by pressing [f] or [J,] while the issue is in the window, until 
the desired level is reached. Long Hand Order Entry may also be 
accomplished. Finally, the trader presses [Confirm] to complete 
the order or press f Reject] to cancel the order. 

Id. at 22:40 - 23:29 (emphasis added). 

In contrast to McCausland's manual order entry and execution technique, Applicants' 

claim 40 recites "preventing, by the electronic trading system, a match of the received trading 

orders when the predetermined order conditions associated with the match result in a locked or 

crossed market." As set forth in Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result. 

(Applicants' Specification at [0090].) McCausland does not teach or suggest preventing a match 
of trading orders when order conditions are invalid and result in a locked or crossed market. 
Instead, McCausland merely describes use of a keypad by a trader to accept bids or offers, 
thereby executing an order. 

b. Broka Fails to Remedy the Deficiencies of McCausland 
As discussed above, McCausland fails to teach or suggest each and every element of 
claim 40, from which claims 41, 42, 55 and 56 depend. Broka fails to cure the defects of 
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McCausland, at least because Broka fails to teach or suggest "preventing, by the electronic 
trading system, a match of the received trading orders when the predetermined order conditions 
associated with the match result in a locked or crossed market" as recited in claim 40. 

Broka relates to "[a] system for monitoring information about debt securities and 
reporting trades in the debt securities market." (Broka at Abstract.) Specifically, Broka 
describes a "regulated, computerized bond trading system has been developed to gather quote 
and trade information from several bond traders and other users, and to organize and 
disseminate such information quickly and reliably." Id. at 1:55-60 (emphasis added). 

Broka' s system provides five main functions, described as follows: 



Trade management is mainly concerned with reporting trades . A 
trade report occurs when users enter bond trade information into 
the FIPS system . FIPS' basic trade reporting functions include 
entering a trade report, modifying a trade report, and disseminating 
a report. Other functions include browsing, statistics gathering, and 
summary updating. 

Quote management is mainly concerned with updating bid and ask 
prices . A quote in FIPS occurs when a user enters a bid and/or 
offer for a particular bond into FIPS . FIPS' quote management 
functions include entering, modifying, withdrawing, restoring, and 
removing quotes. Additional quote management functions include 
monitoring quote activity, disseminating quote data, and setting 
market alerts. 

Market management allows a user to form groups of specific bond 
issues , which then become the user's "markets," and to monitor 
bond information changes directly in the group. Such groups are 
referred to as "Minder" groups. 

Directory services allow users to search databases using different 
criteria . Two such databases are bond issue and FIPS participant. 
For example, a user can browse the bond database to find issues for 
which the user has made quotes or to find issues of a given coupon 
rate and maturity year. A user can browse the FIPS participant 
database to list brokers, dealers, or view-only users. 

FIPS utilities allowing users to customize certain interfaces and 
data presentation formats . For example, user may select certain 
issues to be grouped into "Minder" groups. 
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Id. at 5:39-67 (emphasis added). The Office Action alleges that Broka discloses the "enabling" 
step, but does not allege that Broka discloses the "receiving... authorization" step, the 
"transmitting" step, the "matching" step or the "preventing" step. (Office Action at 8.) 

As set forth above, Broka is directed toward a system for gathering trade and quote data 
entered by users, and making that data available to the users via reports and databases. Broka 
simply fails to teach or suggest at least the "receiving... authorization" step, the "transmitting" 
step, the "matching" step and the "preventing" step as recited in claim 40. 

c. Lawrence Fails to Remedy the Deficiencies of McCausland and Broka 

As discussed above, McCausland and Broka, alone or in combination, fail to teach or 
suggest each and every element of claim 40, from which claims 41, 42, 55 and 56 depend. 
Lawrence fails to cure the defects of McCausland and Broka. 

Lawrence relates to "a computerized municipal bond trading system having the capability 

to conduct a private electronic auction of bid wanteds between a central market-maker and 

multiple remote clients who are prospective bidders." (Lawrence at 3:36-40.) Lawrence 

specifically describes the trading system as follows: 

A selling trader 14, who may be an owning institution or individual 
but is preferably an SEC-registered securities broker dealer, 
transmits one or more job lots 16 of bonds for sale to the municipal 
bond trading system 1 0 maintained by a broker, who functions as a 
"market-maker," at any time convenient to the selling trader 14. 
Transmission of job lots 16 to the municipal bond trading system 
10 can be accomplished in any conventional manner; written, 
faxed, telephoned, or the equivalent, but is preferably electronically 
effected in a file that can be directly processed by the municipal 
bond trading system 10, for example, via confidential e-mail, as are 
communications from the market-maker to the seller, over data 
lines 15. Most preferably, the seller is computer-linked to the 
municipal bond trading system 10 on a LAN or a WAN. 

After appropriate central processing employing the municipal bond 
trading system 10, bid wanteds are circulated to buying traders 12 
in order to solicit bids 18. These functions are described in greater 
detail herein below. Bids 1 8 are received from one or more buying 
traders 1 2 and transmitted to the seller by any suitable means, such 
as fax or computer network, as described above, for further 
processing. If the selling trader 14 accepts the bid 18, the brokers' 
broker marks the lot "for sale" and completes the execution. 
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preferably with the assistance of the municipal bond trading 
system 10, and then transmits customary buy and sell tickets 20 to 
the selling trader 14 for their internal processing. 

Id. at 6:6-32 (emphasis added). The Office Action alleges that Lawrence discloses the 
"authorizing" and "transmitting" steps of claim 40, but does not allege that Lawrence discloses 
the "matching" step or the "preventing" step. (Office Action at 8-9.) 

As set forth above, Lawrence is directed to a system for facilitating bids and execution of 
trades for municipal bonds. Lawrence simply fails to teach or suggest the "matching" and 
"preventing" steps as recited in claim 40. 

d. Lupien Fails to Remedy the Deficiencies of McCausland, Broka, and Lawrence 

As discussed above, McCausland, Broka and Lawrence, alone or in combination, fail to 
teach or suggest each and every element of claim 40, from which claims 41, 42, 55 and 56 
depend. Lupien fails to cure the defects of McCausland, Broka and Lawrence. 

Lupien relates to an "automated securities trading and portfolio management system for 

use by investment managers." (Lupien at 2:60-62.) Lupien describes order execution as follows: 

Orders are executed by the system on a price/time priority basis 
within the system in step 44, although orders could also be 
executed on a price/size/time priority basis. All orders generated 
are forwarded to controller CPU 10 which presents them together 
with those from other clients for display to each client or client 
process in a manner discribed [sic] below. If a purchase order 
matches a sale order (in whole or in part) created for another 
client portfolio the controller will match the two and a trade will 
occur which will be reported to the markets as well as to each 
client's portfolio trading algorithm . If orders are not executed 
within the system, control passes to block 46 where controller CPU 
10 decides, based on recent trading history, where and how much 
of each order to place on which external automated market, broker, 
exchange and/or its own network. 

Id. at 1 1 : 44-60 (emphasis added). When matching orders, Lupien states that: 

A match occurs when a buy order and a sell order agree on security 
name, price, size and terms of the trade. If a match is detected, both 
the buy and sell sides of the order are at block 84. In the case of 
external auto-traders, acceptance is tentative and becomes final 
only when confirmation from the external auto-trader is received 
by the system. Since external auto-traders must themselves confirm 
a match there will be a limited period of time before acceptance or 
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rejection, and, therefore, the tentative acceptance procedure is 
necessary. By contrast, internal auto-traders accept matches 
immediately in real time without tentative acceptance . If either side 
of the trade rejects the match, the order is reopened at block 86 
while the order of the rejecting side is newly time-stamped and 
moved to the rear of its price-priority group. The order of the 
accepting side is not requeued. 



Id. at 13:25-41 (emphasis added). Thus, Lupien's matching techniques either require 
confirmation from an external trader before accepting a match or accept matches immediately. 

The Office Action argues that Lupien discloses the "matching" step of claim 40, and 
alleges that Lupien discloses "presenting [sic] a match responsive to said predetermined order 
conditions" step. (Office Action at 9 (emphasis added).) However, as set forth above, Lupien 
does not teach or suggest preventing a match based on predetermined order conditions as recited 
in claim 40. Instead, Lupien provides that matches are either (i) tentatively accepted and become 
final only upon external confirmation or (ii) accepted immediately in real time. (Lupien at 13:25- 
41.) Indeed, Lupien does not teach or suggest the step of "preventing, by the electronic trading 
system, a match of the received trading orders when the predetermined order conditions 
associated with the match are invalid and result in a locked or crossed market" as recited in claim 
40. 

e. Hushes Fails to Remedy the Deficiencies of McCausland, Broka, Lawrence and 
Lupien 



As discussed above, McCausland, Broka, Lawrence and Lupien, alone or in combination, 
fail to teach or suggest each and every element of claim 40, from which claims 41, 42, 55 and 56 
depend. Hughes fails to cure the defects of McCausland, Broka, Lawrence and Lupien. 

Hughes relates to "systems and methods... for supporting the trading of bonds in a 
computerized system using broker dealers as intermediaries." (Hughes at Abstract.) Hughes 
describes the order matching of FIG. 8 as follows: 



The matching process is performed for broker dealers, that is, for 
bids and offers received by a broker dealer. The system performs 
the matching by first generating a list of candidate offers that 
partially match a specific order based on, in one embodiment, 
CUSIP and price, step 240, accounting in price for any markup 
applied by that broker dealer to the specific counterparty 
submitting each candidate offer. If the list of candidate offers 
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contains only one offer, this offer is deemed to match and the 
system updates the order and trade files accordingly to reflect that 
a trade has occurred , step 262. If the offer was subject, the parties 
are first notified and confirmation is requested before the trade is 
executed, as explained above. 

If the candidate list contains multiple orders, one of such orders 
must be selected. In some embodiments, the party that generated 
the original order can specify whether it prefers a match to occur 
on price or on amount of securities in the trade. If the user 
specified a match on price, step 244, the candidate list is searched 
for one or more orders at the best price , step 246. If multiple such 
orders at the best price are found, step 248, the system selects the 
one of such orders having the largest amount of securities, step 
250. Otherwise, the order at the best price is selected from the list, 
step 252. If the user specified a match based upon amount, the 
candidate list is searched for orders at the highest amount , step 
254. If multiple such orders at the highest amount are found, step 
256, the order with the best price is selected, step 258; otherwise, 
the order at the highest amount is selected, step 260. If in either 
instance after narrowing the list based on price and amount the 
candidate list still contains multiple orders, one of the orders is 
selected at random or based on an earlier time of receipt of the 
order. The selected order is used for the transaction, and the order 
files and trade files are updated accordingly to reflect that the 
transaction has occurred , step 262. 

Id. at 15:35 - 16:3 (emphasis added). 

In Hughes: 

The rebroker method populates a SubOrder table that is used for 
order viewing. This table contains the ID of the order, the route 
number, the broker/dealer the order was rebrokered to, and the 
updated price. This table is used for efficient order viewing. When 
viewing an order, the SubOrder table is queried for the customer's 
broker/dealer. The SubOrder table is populated by querying 
CounterPartyOrderSituation and Path tables, described in greater 
detail below. Once a component has been rebrokered the matching 
process is called to determine if there are two orders that qualify as 
a match. Once a match occurs the route number is used to notify 
all parties involved in the match. This includes the buying and 
selling customer. All intermediaries are notified of any markup or 
commission received on the match. The order is then marked as 
inactive and a record is written to the match table to record the 
matching transaction . 
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Id. at 19:29-44 (emphasis added). 

The Office Action alleges that: 

It would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to combine the disclosure of 
McCausland, Broka, Lawrence and Hughes and provide an 
electronic trading system to poll the pending order list of bids and 
offers and find suitable matched counter orders with predefined 
rules once the matched orders are filled and trade is created the 
matched orders are executed otherwise , marked for invalid to be 
send back to the broker to fix the order [Fig. 2] . 

(Office Action at 9 (emphasis added).) 

As set forth above, Hughes teaches that "once a match occurs... [t]he order is marked as 
inactive." (Hughes at 19:39:44.) The Office Action claims that Hughes teaches that orders are 
"marked for invalid to be send [sic] back to the broker to fix the order." (Office Action at 9.) 
However, in contrast to Hughes's matching techniques and the interpretation of Hughes 
advanced by the Office Action, Applicants respectfully submit that claim 40 does not recite 
marking orders as inactive or marking them invalid and sending them back to the broker to be 
fixed. Indeed, Hughes simply does not teach or suggest the step of "preventing, by the electronic 
trading system, a match of the received trading orders when the predetermined order conditions 
associated with the match are invalid and result in a locked or crossed market" as recited in claim 
40. 

For at least the reasons set forth above, the cited references McCausland, Broka, 
Lawrence, Lupien and Hughes, alone or in combination, fail to teach or suggest each and every 
element of Applicants' claim 40. In addition, the cited references fail to teach or suggest each 
and every element of claims 41, 42, 55 and 56 because those claims depend either directly or 
indirectly from claim 40. Therefore, Applicants respectfully request reconsideration and 
withdrawal of this ground of rejection. 

III. Rejection of Claims 61-65, 67-69, 71-72 and 74-75 under 35 U.S.C. § 103(a) 

The Office Action rejected claims 61-65, 67-69, 71-72 and 74-75 under 35 U.S.C. § 
103(a) as being unpatentable over McCausland in view of Lawrence, Lupien and Hughes. 
(Office Action at 1 1-20.) For a rejection under § 103 to be proper, the references must expressly 
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or impliedly suggest the claimed invention taken as a whole. Additionally, the combination must 

not render either reference inoperable. 

Like claim 40, claims 61 and 71 recite: 

preventing, by the computer trading system, a match of the 
received trading orders when the predetermined order conditions 
associated with the match result in a locked or crossed market. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" step of claim 
40. See Section Il.a, supra. Also, as discussed above, Lawrence, Lupien and Hughes fail to 
remedy the deficiencies of McCausland with respect to at least the "preventing" step of claim 40. 
See Sections II.c, Il.d and II.e, supra. 

For the same reasons, McCausland, Lawrence, Lupien and Hughes, alone or in 
combination, fail to teach or suggest each and every element of claim 61, from which claims 62- 
65 and 67-69 depend, and claim 71, from which claims 72 and 74-75 depend. Therefore, 
Applicants respectfully request reconsideration and withdrawal of this ground of rejection. 

IV. Rejection of Claims 58, 59 and 73 under 35 U.S.C. § 103(a) 

The Office Action rejected claims 58, 59 and 73 under 35 U.S.C. § 103(a) as 
being unpatentable over McCausland in view of U.S. Patent No. 6,343,278 to Jain et al. ("Jain"), 
Hughes, APA and Lupien. (Office Action at 20-24.) In the section discussing the rejection of 
claims 58, 59 and 73, the Office Action states, "[r]e. Claim 73, claim is rejected with same 
rational [sic] as claim 72 above." (Id. at 24). However, Applicants do not find in the Office 
Action any explanation of how the combination of McCausland, Jain, Hughes, APA and Lupien 
applies to claim 72. Applicants respectfully submit that the same arguments provided in Section 
III above with regard to claim 72 are equally applicable here. 

For a rejection under § 103 to be proper, the references must expressly or impliedly 
suggest the claimed invention taken as a whole. Additionally, the combination must not render 
either reference inoperable. 

Like claims 40, 61 and 71, claim 58 recites: 

preventing, by the computer trading system, a match of the 
received trading orders when the predetermined order conditions 
associated with the match result in a locked or crossed market. 
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As discussed above, McCausland fails to teach or suggest at least the "preventing" step of claims 
40, 61 and 71. See Sections II. a and III, supra. Also, as discussed above, Lupien and Hughes fail 
to remedy the deficiencies of McCausland with respect to at least the "preventing" step of claim 
40. See Sections Il.d-e and III, supra. Jain fails to remedy the deficiencies of McCausland, 
Lupien and Hughes. 

Jain relates to a "computerized trading system for trading financial instruments or other 
commodities between traders at trader terminals, wherein the trading system facilitates manual 
entry and possible revision of a group of related orders for derivatives based on a common 
underlying currency or other commodity." (Jain at 1:66 - 2:4.) Jain describes order matching as 
follows: 

Orders that are compatible are matched by the dealing system. 
Newly submitted bid and buy orders are matched against 
outstanding offer orders. Newly submitted sell and offer orders are 
matched against outstanding bid orders. 

Any order submitted into the system is first matched against all 
existing bids and offers at the maker's Arbitrator. The existing 
orders are considered in price/time order in search o f compatible 
orders. If a compatible order is found, the two orders are 
"matched" and a deal is initiated for the amount equal to the 
minimum of the two order amounts . The process continues until the 
remaining three-month equivalent amount of the submitted order 
becomes less than the value of the minimum notional amount 
parameter, or until there are no compatible orders. 

Id. at 13:4-7, 18-27 (emphasis added). 

In contrast to Jain's order matching techniques, claim 58 recites "preventing, by the 

electronic trading system, a match of the received trading orders when the predetermined order 

conditions associated with the match are invalid and result in a locked or crossed market." As set 

forth in Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result." 
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(Applicants' Specification at [0090].) Jain simply does not teach or suggest preventing a match 
of trading orders when predetermined order conditions result in a locked or crossed market. 
Instead, Jain merely performs a compatibility determination between newly submitted sell and 
offer orders against outstanding bid orders, and compatible orders are considered in price/time 
order. 

For at least the reasons set forth above, the cited references McCausland, Hughes, Lupien 
and Jain, alone or in combination, fail to teach or suggest each and every element of Applicants' 
claim 58. In addition, McCausland, Hughes, Lupien and Jain fail to teach or suggest each and 
every element of claims 59 and 73 because those claims depend directly or indirectly from claim 
58. Therefore, Applicants respectfully request reconsideration withdrawal of this ground of 
rejection. 



Applicants' discussion of particular positions of the Office Action does not constitute a 
concession with respect to any positions that are not expressly contested by the Applicants. 
Applicants' emphasis of particular reasons why the claims are patentable does not imply that 
there are not other sufficient reasons why the claims are patentable. 

In view of the foregoing remarks and the inability of the prior art to anticipate, suggest or 
make obvious the subject matter as a whole of the invention disclosed and claimed in this 
application, all the claims are submitted to be in a condition for allowance, and notice thereof is 
respectfully requested. If the Examiner feels that a telephone conference would expedite 
prosecution of this case, the Examiner is invited to call the undersigned. 



CONCLUSION 



Respectfully submitted, 
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